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Abstract 

We present an abstract machine specification for TyCO (Typed Concurrent Objects), a name- 
passing caicuius tliat aims at capturing fundamentai concepts present in Concurrent Object- 
Oriented Languages. 

TyCO lias built-in labeled messages and ephemeral object s that communicate asynchronously. 
Persistent objects are supported through instantiation of recursive classes. Concurrency is 
pervasive and synchronous communication can be implemented by passing continuations in 
messages. Strong, static typing is provided by a type inference algorithm that supports a form 
of predicative polymorphism. 

This paper describes the abstract machine framework in detail, including how it evolves from 
TyCO and some important properties it can be shown to possess. 

Keywords: Object-Oriented, Concurrency, Language, Implementation 

1 Introduction 

Name-passing process calculi attempt to formally describe the interaction between concurrent pro- 
cesses. This interaction involves not only point-to-point communication but also the notions of 
process mobility and communication topology. These calculi originate in Milner's CCS [13] (Calculus 
of Communicating Processes) in which processes interacted through synchronization (the simplest 
form of communication). 7r-calculus [15] was the first calculus in which processes could send one 
upright at a time through a named channel. This is called the monadic 7r-calculus. Later on this 
calculus was extended to allow for tuples to be exchanged in a single message, giving rise to the 
polyadic 7r-calculus [14]. This extension eased the programming task but did not increase the power 
of the calculus itself. Instead it introduced the possibility of protocol errors. These occur when 
two processes communicate exchanging tuples with different lengths. Such errors can be detected 
at compile time by using appropriate type inference algorithms, thus enforcing some kind of typing 
discipline on the usage of channels [14, 21, 19]. 

Recently, a considerable effort has been devoted to the problem of introducing objects into these 
calculi [8, 20, 24] thus providing a formal framework for modeling concurrent object-oriented lan- 
guages. TyCO [20, 22] is just one of these efforts. It is a calculus that formally describes the 
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concurrent interaction of ephemeral objects through asynchronous communication. The calculus 
grows from the polyadic 7r-calculus and its monomorphic type system, by introducing recursive types, 
a polymorphic type system [22], templates and variables over templates. Synchronous communication 
can be achieved as usual by incorporating in messages an extra name intended to convey the result 
of the communication. The fundamental entities of the calculus are messages and ephemeral objects. 
Templates are specifications of processes abstracted on a sequence of variables. They allow classes to 
be modeled from which run-time objects may be instantiated. 

Example. Consider the following TyCO template definition for a memory cell with write and read 
methods: 

Cell = (self value) self \> {write : (newval) Cell{self newval) & 
read : (replyto) replyto < val : value , Cell{self value)} 

An instance of Cell would be Cell{x 2) for some variable x. The value in the memory cell is the 
integer 2. Sending a message x < write : 5 we replace the current cell contents with 5: 

X < write : b , X \> {write : • • • } — > Cell{x 5) 

On the other hand, if we want the value in the cell to be read and sent to destination r then we 
invoke method read as follows: 

X < read : r , x \> {write : • • • } — > r < val : 2 , Cell{x 2) 

The abstract machine evolves from the object calculus by defining a static semantics (a type inference 
system) and a dynamic semantics in the form of a set of reduction rules. The abstract syntax of the 
calculus also evolves into a more compact object assembly language. 

The remainder of this paper is organized as follows: sections 2 and 3 describe the abstract machine, its 
abstract syntax and dynamic semantics; section 4 introduces the static semantics; section 5 describes 
some of the properties verified by the abstract machine and, finally; section 6 compares our approach 
to other related work. 

2 Abstract Syntax 

Sequences and finite maps 

1. e denotes the sequence ei . . .e^ > 0) of elements of some syntatic category, and {e} denotes 
the set {ei, . . . ,e„}. The empty sequence is denoted by e. 

2. When A and B are sets, A i-^ B denotes the set oi finite maps (partial functions with finite 
domain) from A io B. 

3. A finite map is often written explicitly in the form {ai : hi, . . . , a^ : h^} for k > 0. In particular, 
the empty map is {}. When a = ai . . . a^ and & = &i we abbreviate the above finite map 
to a : &. 

4. When / and g are finite maps, the map f + g, called / modified by g, is the finite map with 
domain dom(/) U dom((jf) and values 

(/ + g){a) = if a G dom((jf) then g{a) else f{a). 

5. When / is a finite map and V a set, the map / \ V^, is the finite map with domain dom(/) \ V 
and values 

{f\V){a) = f{a). 

6. When / is a finite map and V a set, the map f \ V , pronounced / restricted to V , is the finite 
map with domain dom(/) fl V and values 

{f\V){a) = f{a). 
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Identifiers and Syntactic Categories 



c G Const 
x,y, z G Var 

u,v ^ Var U Const 
/ G Label 
X e CVar 



Constants (Integer and Boolean) 
Variables 



Values 



Labels 



Class variables 



P e Proc 



Processes 



P G Thread = Proc* 



Threads 



M e Meth = Label i-^ Tempi 
A G Tempi = Var* x Thread 



Templates 
Classes 
Class Bindings 



Methods 



C e Class = Var* x Var x Meth 
D e DBind = CVar ^ Class 



Syntax 



p 


::= u <\l : [u] 


yO M \ \x\P \ X[u\ 1 def £) in P 


p 


■■■■= Pi\---\Pk 




M 


■■■■= {h-Ai,. 


• , Ik ■ Ak} 


A 


::= ix)P 




D 


■■■■= {Xi : Ci , 


■ ■ , Xk : Ck} 


C 


::= {x}y\>M 





The sequence P = Pi \ ... \ P^ for = 0 is designated by the keyword nil. 

Syntatic conventions 

• The names in the sequence x in a template yl or a class C are pairwise distinct. 

• The set of methods M for an object is written as {/i : Ai ; . . . ; Ik '■ Ak} in abstract machine 
programs. 

• The set of class bindings {Xi : C'l , • • ., Xk : C^} in a class statement is written as Xi = 
C'l and . . . and Xk = C'k in abstract machine programs. 



Queues are used to implement the run-queue as well as the messages/object queues; hence the 
parametric definition. 



3 The Abstract Machine 



3.1 Queues 



Queue(yl) ::= A:: . . .:: A \ 
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3.2 Free identifiers 

Identifiers take the form of value- and class- variables. These may occur free or bound in processes. 
The set of free value-vanahles in a process is inductively defined by: 



fv(c) = 0 


fv{u<\l : [u\) =fv(M)Ufv(M) 


fv(a;) = {«} 


iv(y\>M) =fv(t/) Ufv(M) 


iv{\x\P) = iv{P)\{x] 


fv(M) =U,6dom(M)fv(M(0) 


fv(Pi|...|Pfe) =fv(Pi)U...Ufv(Pfe) 


fv(D) =Ux6domP)fv(i?(X)) 


hi(X[u]) = fv(M) 


fv({x}P) = iv(P) \ {x} 


fv(def DmP)= hi(D) Ufv(P) 




The set of hound value-vanahles is defined accordingly. A process P is said to be closed for value- 


vanahles if fv(_P) = 0. 




The set oi free class-vanahles in a process is inductively defined by: 


fc(c) = 0 


fc(M < / : [tT]) = 0 


fc{x) = 0 


ic(y \>M)= ic(M) 


{c{\x\P)= {c{P) 


fc(M) =U,6dom(M)fc(M(0) 


{c{Pi\...\Pk)=fc{Pi)U...U{c{Pk) 


{c{D) = (Ux6domp)fc(i?(X))) \dom(D) 


fc{X[u]) = {X} 


fc({x}P) = ic(P) 


fc(def D\n P)= ic(D) U (fc(P) \ dom(D)) 




The set of hound class-vanahles is defined accordingly. A process P is said to be closed for class- 


vanahles if fc(_P) = 0. 




3.3 Identifiers and Syntactic Catej 


gories 


a G Name 


Names 


v G Val = Name U Const 


Values 


B e VBind = Var i-^ Val 


Variable bindings 


T e TBind = CVar ^ (VBind x Class) 


Class- variable bindings 


ms G QComm = Queue (Label x Val*) 


Communication queue 


Ms e QMeth = Queue (VBind x Meth) 


Method-closure queue 


Q e QBind = Name i-^ (QComm U QMeth) 


Communication/Method-closure queues 


R G RunQueue = Queue (VBind x Thread) 


RunQueue 


S G State = TBind x VBind x QBind x Thread x RunQueue Machine state 



Variable bindings B are used with domain Var U Const. It follows that: 

„ , , ( u if M G Const 
^ ' [ v if u : v e B 

3.4 Restrictions on the Initial Process 

1. The initial process is closed for class- variables and value- variables. 



5 



2. All bound variables in the initial process are distinct. 

3. The initial process is well typed (see section 4). 



3.5 The initial and the final state 

The abstract machine starts computing with an empty run-queue, no bindings in T and B and no 
queues in Q. Thus the initial state is: 



where P is the initial thread. The machine halts when no rule can be applied, that is when a state 
of the form below is reached. 

_, _, -, nil,* 

3.6 Reduction 

Rules transform states into states. In the sequel, comments accompanying rules indicate conditions 
that must be met for the reductions to be successful. Failure to comply with any one of these 
conditions will deadlock the machine. 

The ScHED rule detects the end of the current thread and starts executing the next one in the 
run-queue. 

T, _, 0, nil, {B,P)::R — y T, B, Q, P, R (Sched) 

The Scop rule introduces a new local variable within a thread. For a process | a; | -P, the rule adds 
a binding from variable a; to a fresh name a, and creates a new empty queue for a in Q. Execution 
continues with thread P . 

a (fi dom((5) 



T, 5, 0, I a; I P I P', i? ^ T, 5 + {a; : a}, 0 + {a : .}, P I P', R 



(Scop) 



Comment, x ^ dom(5) by the variable renaming assumption. 

The Dee rule introduces new classes. Given a process def D in P, for each definition X = C in D, 
the rule adds a bind X : (B, C). Execution continues with thread P. 

T, B, Q,de^ D\n P \ P',R — > T + {X : {B , C) \ X = C e D}, B,Q,P\ P' , R 

(Dee) 

Comment. dom(T) fl dom(_D) = 0 by the variable renaming assumption. The Red rules are 
responsible for contraction of redexes. The RedMsg ( RedObj ) rule takes a message (an object) 
from the current thread, a matching object (message) from the appropriate object (message) queue, 
and place the body of the invoked method plus the variable bindings in the run-queue for later 
execution. The RedInst rule creates an object, instance of some class, and reduces it immediately 
with a compatible message. In all cases execution continues with the current thread. 

B(y)=a Q(a) = (B',M)::Ms M{l) = {x)P' 
T,B,Q,y<il:[u\ \P , R — y T,B,Q + {a: Ms}, P, R:: {B' + {x : B{u)},P') 

(RedMsg) 

B(y) = a Q(a) = (I : [v]) :: ms Mil) = {x)P' 
T,B,Q,y\> M\P,R — > T,B,Q + {a: ms} , P , R:: {B + {x : v},P') 

(RedObj) 

T(X) = (B',{x}y\> M) B"(y) = a Q(a) = (I : [v\) :: ms M{l) = {z)P' 
T,B,Q,X[u\ \P,R — y T,B,Q + {a: ms} , P , R::{B" + {z:v},P') 

(RedInst) 
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where B" = B' -\- {x : B{u)} in the RedInst rule. 
Comment, y G dom(5) since processes are closed. 
Comment. I G dom(M) since programs are well typed. 
Comment. length(£')=length(t/) since programs are well typed. 

Comment, a G dom((5). Since processes are closed and well-typed, the binding must have been 
placed by the Scop-rule. 

Comment. X G dom(T) since programs are closed for class- variables. Similarly, {«} C dom(5). 

Comment. {£} n dom(5') = 0 since dom(5') = iv{(x)y \> M) and {£} n fv(_P') = 0. 

The Queue rules are responsible for the queuing of messages and objects. They are used whenever 
immediate reduction of messages, objects or class instances is not possible. The QueueMsg ( 
QueueObj ) rule takes a message (an object) and place it in the appropriate message (object) 
queue. Reduction will occur when a matching object (message) is later scheduled for execution. 
Execution of the current thread continues. The QueueInst rule creates an object, instance of some 
class, and places it in the appropriate object queue. 

B[y) = a Q{o.) = ms 
T,B,Q,y <\l -.[ul \P,R — > T,B,Q + {a: ms::l : [B{u)]},P,R 

(QueueMsg) 

B{y) = a Q{a) = Ms 
T,B,Q,y\>M \P, R — y T, B ,Q + {a : Ms:: {B, M)}, P, R 

(QueueObj) 

T(X) = (B' ,{x)y[> M) B" = B' + {x : B(u)} B" (y) = a Q(a) = Ms 
T,B,Q,X[u] \P,R — y T,B,Q + {a: Ms::{B" , M)} , P , R 

(QueueInst) 

Comment, y G dom(5) since processes are closed. 

Comment, a G dom((5). Since processes are closed and well-typed, the binding must have been 
placed by the Scop-rule. 

Comment. X G dom(T) since programs are closed for class- variables. Similarly, {«} C dom(5). 

Comment. Packing variable bindings when making a closure for a thread or a set of methods, or de- 
referencing values when a thread is assigned for execution, is one major task of the abstract machine. 
These operations can be optimized both for space and speed. 

First, when packing variable bindings into a method closure we do it per label, that is, instead of a 
single pair in VBind x Meth we use a collection of pairs in VBind x Tempi: 

{/ : (5 \iv{A),A) \ l:A^M] 

at the cost of some duplication of bindings, this significantly decreases the average cardinality of the 
B component during computations. Bindings for the bound variables (parameters) are supplied when 
the thread is activated. For de-referencing values we use the following equality to avoid redundant 
operations: 

„ , , { u if M G Const 
^ ' \ V if u : V e B 

To end this section we present a full listing of the rules for the abstract machine: 
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ScHED T, Q, nil, {B,P)::R — > T, B, Q, P, R 

a (fi dom((5) 



RedMsg 
RedObj 
RedInst 
QueueMsg 
QueueObj 
QueueInst 



Scop — - — 

T,B,Q,\x\P\P',R^T,B^{x:a],Q^{a:*},P\ P' , R 

Dee T, B, Q,de^ D \n P \ P' , R — > T + {X : {B , C) \ X = C e D}, B,Q,P\ P' , R 

B(y)=a Q(a) = (B',M)::Ms M{l) = {x)P' 



T,B,Q,y<il: [u] \P,R — > T,B,Q + {a: Ms}, P, R:: {B' + {x : B{u)},P') 

B(y)=a Q(a) = (I ■.[v\)::ms M{l) = {x)P' 
T,B,Q,y\> M\P,R — >T,B,Q + {a : ms}, P, R::{B + {x : v}, P') 
T(X) = (B',{x}y\> M) B"(y) = a Q(a) = (I : [v\) :: ms M{l) = {z)P' 
T,B,Q,X[u\ \P,R — y T,B,Q + {a: ms}, P, R:: {B" + {z : v}, P') 
B{y) = a Q{o.) = ms 
T,B,Q,y<\l : [u\ \P,R — > T,B,Q + {a: ms::l : [B{u)]},P,R 

B{y) = a Q{a) = Ms 
T,B,Q,y\> M \P, R — > T, B , Q + {a : Ms:: {B, M)}, P, R 

T(X) = (B',{x}y\> M) B" = B' + {x : B(u)} B"(y) = a Q(a) = Ms 
T, B, Q, X[u\ \P, R — >T,B,Q + {a: Ms:: {B", M)}, P, R 



3.7 Basic Arithmetic and Logic Operations 

The abstract machine supports two primitive data types: booleans and integers. Actually any of 
these data types could be encoded in TyCO [20] and their operations manipulated by the abstract 
machine just as conventional processes. However, performance constraints urged the definition of 
built-in operations (reduction rules) for these common data types. 

The basic logic operations are provided by the following rules: 



T,B,Q,{c< not : 


[r]) 


\P,R - 


T,B,Q, 


[B 




<\ val 


h5( 


c)]) \P,R 


T,5,0,(c<and : [c' 


r]) 


\P,R - 


T,B,Q, 


{B 




<\ val 


[B{c 


A5(c')]) \P,R 


T,5,0,(c<or : [c' 


r]) 


\P,R - 


T,B,Q, 


(B 




<\ val 


[5(c 


V5(c')]) \P,R 


T,5,0,(c<xor : [c' 


r]) 


\P,R - 


T,B,Q, 


(B 




<\ val 


[5(c 


V5(c')]) \P,R 


T,5,0,(c<eq : [c' 


r]) 


\P,R - 


T,B,Q, 


(B 




<\ val 


[5(c 


= B{c')]) \P,R 



Booleans can intuitively be seen as objects of the form below, one for each boolean c, permanently 
in the object-queue. 

c [> {not : (r) r < val : [-'c], . . .} 

We also introduce the conditional construct if . . . as a built-in both for performance and for keeping 
the design coherent with mappings of higher order constructs such as pattern matching [20]. The 
reduction rules for if c then P else Q (where c is a boolean constant) are the following: 

T,B,Q,H true then P' else P" \P,R — > T,B,Q,P' \ P,R 
T, 5,0, if false then else I — > T,B,Q,P"\P,R 
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Finally, the primitive integer operations are implemented by the following rules: 



T,5,0,(c<add : 


[c' 


r]) 


P,R - 


T,B,Q, 


(B 




<\ val : 


[B 


c) 


+ 5(c')]) \P,R 


T,5,0,(c<sub : 


[c 


r]) 


P,R - 


T,B,Q, 


[B 




<\ val : 


[B 


c) 


-B{c')]) \P,R 


T,B,Q, {c<\ mul : 


[c' 


r]) 


P,R - 


T,B,Q, 


(B 




<\ val : 


[B 


c) 


■B{c')]) \P,R 


T,5,0,(c<div : 


[c' 


r]) 


P,R - 


T,B,Q, 


(B 




<\ val : 


[B 


c) 


div 5(c')]) \P,R 


T,B,Q, {c<\ mod : 


[c' 


r]) 


P,R - 


T,B,Q, 


(B 




<\ val : 


[B 


c) 


mod 5(c')]) \P,R 


T,5,0,(c<eq : 


[c' 


r]) 


P,R - 


T,B,Q, 


(B 




<\ val : 


[B 


c) 


= 5(c')]) \P,R 


T,5,0,(c<geq : 


[c' 


r]) 


P,R - 


T,B,Q, 


(B 




<\ val : 


[B 


c) 


>=B{c')]) \P,R 


T,B,Q,{c<gt : 


[c' 


r]) 


P,R - 


T,B,Q, 


(B 




<\ val : 


[B 


c) 


>B{c')]) \P,R 


T,B,Q,{c<i\eq : 


[c 


r]) 


P,R - 




[B 




<\ val : 


[B 


c) 


<=B{c')]) \P,R 


T,B,Q,{c<i\t : 


[c' 


r]) 


P,R - 




(B 




<\ val : 


[B 


c) 


<B{c')]) \P,R 



Integers can intuitively be seen as objects of the form below, one for each integer c, permanently in 
the object-queue. 

c \> {add : (c' r) r < val : [c + c'], . . . } 

4 Type Inference 

This section presents a type system assigning types to the free names in a process. 

Typable processes are exempt from run-time errors. We say a process P contains a possible run-time 
error if the initial state 0, 0, 0, _P, • reduces to a state T, B,Q,y<\l : u \ P,R with Q(a) = (5', M)::Ms 
but the RedMsg rule cannot be applied because: 

1. label / is not in M - the so called message not understood error, (similarly for the RedObj and 
Red Inst rules); 

2. although / is in M , and M{1) = (x)P , the number of actuals in x does not match the number 
of forwards in x (similarly for the RedObj ,RedInst and QueueInst ). 

Types for names are built from an infinite set of type variables, and the set of labels introduced in 
the previous section, by means of record and recursive type constructors. We use t,t', ■ ■ ■ to range 
over type variables, a,/3, • • • to range over types, and a, /3, • • • to represent (finite, possibly empty) 
sequences of types. The set of monomorphtc types is given by the grammar: 

a ::= t \ {li : cTi, • • • , /„ : a"^} | ^it.a 
where /i, • • • ,ln are pairwise distinct labels. 

A simple extension of the monomorphic type system allows to abstract a type for an abstraction on 
a particular type variable, and to instantiate an abstracted type into different monomorphic types. 
Types for abstractions fall into two classes: monomorphtc types as sequences of types for names, and 
polymorphic types constructed using V [5]. The set of polymorphic types is given by the following 
grammar: 

(T ::= a \ 'it. a 

A type of the form {/i : cTi, •••,/„: a"^} is intended to describe some collection of names identifying 
objects containing n methods labeled with h, - ■ ■ ,ln, and whose arguments of method li belong to 
the types in a,-. Types are interpreted as regular infinite trees. A type of the form jit. a (with 
a ^ t denotes the regular infinite tree solution of the equation t = a. If a is a type, denote a* its 
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associated regular infinite tree. An interpretation of recursive types as infinite trees naturally induces 
an equivalence relation on recursive types, by putting a /3 if a* 

Type assignments to names are formulae x : a, for x a name and a a type. While we assign types 
to names, to processes we assign typings. Typings, denoted ?, A, • • •, are sets of type assignments 
where no name occurs twice. The typing ? — {x} is obtained from ? by removing the type assignment 
associated with x. The expression ? (x) denotes the type associated with x in 7 . 

Universal quantifiers can only occur at the top level of types. This is a direct consequence of the 
definition of the set of polymorphic types. A polymorphic type of the form Vt i . • • • Vt„ .a is abbreviated 
to Vti • • - tn.a, where ti, - ■ ■ ,t„ are the bound variables of the type. (There is another binding for 
type variables, namely i^t.a binds t in a.) We assume the usual notion of substitution of a type a for 
the free occurrences of a type variable t in a type a, and denote it by (T[a/t]. A type variable occurs 
free in a typing ? if it occurs free in some type in ? . 

Type assignments to abstraction variables are formulae X : a, for X an abstraction variable and a 
a polymorphic type. Bases, denoted B, B' , ■ ■ ■ , are sets of type assignments to variables where no 
variable occurs twice. Similarly to typings, we write B{X) for the type associated with X in B. A 
type variable occurs free in a basis B if it occurs free in some type B. 

When 5 is a base containing only sequences of types, the closure of B with respect to ? , closr B, is 
the basis {X : 'it. a \ B{X) = a and t are the variables occurring free in a but not in 5 or ? . 

Typing assignments to processes are statements B,7 \~ P, whereas type assignment to abstractions 
are statements B,7 \- A : a. 

The type system is composed of the following axioms and rules: 

Values are assigned types. We assume a predicate typeof{c) for each constant c. Sequences of values 
are assigned sequences of types. 

^ \~ V =^ a ^ \~ V =^ Ci 

? h c ^ typeof (c) — ^ -? u — ~ 

! ,x : a r X a ! r vv r aa 

A Method I : A is assigned a record type {/ : a} for a the type of the formal parameters of the 
method. 

B,7hA^a B,7hM^a B,7hM'^a' 



B,7 'rl : A^ {I -.a) B ,7 h M + M' ^ a + a' 

A Communication I : v is assigned a record type containing a component / : a, for a the type of v. 

7 \- V ^ a a' (l) = a 
B,7 \-l -.v^ a' 

Abstractions {x)P (that is, the body of a method or a class) is assigned the type of its formal 
arguments. 

B,7 h P^7 7 \- x^ a 



B,7 - {x} h {x)P => a 



A Class Binding, X = C is assigned a base where the type a of its formal parameters is assigned to 
X. 

B,7hC^a B,7hD^B B,7 h D' ^ B' 



B,7 h X = C ^ {X -.a] B,7 h D + D' ^ B + B' 
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As for Processes, a message v <l I : v is ok if the type of v contains a component / : a, for a the type 
of V. The type of an object x \> M is the type of the methods M . 

B,7hv^a 7(v) = {I : a,---} B,7hM^a 7 (x) = a 

B,7 \- v<il -.v^ ok B,7 \- x\> M ^ ok 

A thread is ok if every constituent process is ok. A scope restriction | a; | _P is oA; if _P is ok; since x is 
bound in P we remove its binding from the typing. 

B,7 h Pi^ ok ■■■ B,7 h Pk^ ok B,7 h P^ ok 



B,7 h Pi\---\Pk,Qh ok B,7 -{x}h\x\P^ ok 

A class instantiation is ok if the type for X is compatible with the type a of the arguments v. A def 
process is ok if P is ok with the types for the new class definitions added to base B. 

B(X) y a 7\-v^a B,7hD^B' B + c\osr(B'),7 h P ^ ok 
B,7hX[v\^ok B,7 h def D\n P ^ ok 



We conclude this section with a brief overview of some important properties of the type system. The 
free names in a process constitute the interaction points of the process, and the types of the names 
describe, in some sense, the interface to the process. Typings for typable processes assign types to 
all free names in the processes. 

Subject reduction ensures that a typing for a process does not change as the process is reduced. As 
a corollary, typable processes do not encounter errors at runtime. 

Decidability of typing assignment (given B, P , and ? , is it the case that B,7 \- P 7) and computability 
of typing existence (given P, is there a B,7 such that B,7 \- P 7) are two properties verified by 
the system despite the fact that the system possess no simple notion of subsumption (and hence of 
principal typings). 



5 Some Properties of the Abstract Machine 

We first overview the semantics for TyCO . 

5.1 Operational Semantics of TyCO 

Scope restriction \ x\P and abstractions {x)P are the name binding operators in the calculus, binding 
the free occurrences of x and x in the respective bodies P. The set of free names in a process P, 
notation fn(_P), is defined accordingly. We assume the usual notion of simultaneous substitution of 
names v for the free occurrences of names x in a process P, notation P{^ /g}, defined only if the 
lengths of v and x match, and the names in x are pairwise distinct. 

Declarations def Xi = Ai and . . .and X„ = A„ in P constitute the only variable binding operator 
binding each variable Xi in each abstractions Aj , as well as in process P. The set of free abstraction 
variables in a process P, notation fv(_P) is defined accordingly. The domain of an abstraction binding 
D, notation dom(_D), is the set {Xi, . . . , X„} when D is of the form Xi = Ai and . . . and X„ = A„. 

Alpha conversion is defined in the usual way, both for names and for abstraction variables. Structural 
congruence over processes simplifies the treatment of reduction. Following Milner [13], we define = 
to be the smallest congruence relation over processes generated by the following rules. 

1. -P = Q if -P is a-convertible to Q, 
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2. P \ Q = Q \ P, and {P \ Q) \ R = P \ {Q \ R), and 0 \ P = P, 

3. \x\0=0, \xy\P =\yx\P, and \ x\P,Q =\x\{P,Q) if x ^fn(O), 

4. def £) in 0 = 0, (def D \n P) \ Q = def D \n P \ P' if dom(D) n fv(0) = 0, 

5. def D in (def D' in P) = def and D' in P if dom(£)) n dom(D') = 0, 

6. def X = (?7)0 and £) in \x\(X[a\\ P) = def X = (y)Q and D \n \x\(Q[^ P), 

7. M = # if M is a permutation of N , and D = D' if D' is a permutation of D. 

One-step reduction, notation _P — Q, is the smallest relation generated by the following rules. 
(Com) a<\l[v\\a\>M ^ Pf/s] where M(l) = (x)P 



P ^ P' P ^ P' P ^ P' 

(Par) — (Res) , , , , (Def) 



PIO^P'IO ' ' \x\P^\x\P ' ' def D\n P ^def D\n P 

P' = P P^Q Q = Q' 



(Struct) 



P'^Q' 



Multi-step reduction, or simply reduction, notation _P ^ Q, is the relation = U — t-"*", where is the 
transitive closure of — 

5.2 Translating Machine States into TyCO processes 

In this section we encode the abstract machine states into equivalent TyCO processes. 

The Queue associated with name a is encoded as sequences of messages, objects or just the nil process. 

[a:.l'=nil 

I a : ms : : m] [ a : msj ,a<\m 
la : Ms::(B,M)Msj =-^[0 : Msj,a\>MB 
The encoding [Q] being the encodings for the queues put in parallel. 

def 

l{ai : gi, • • • ,a„ : = [ai : gi] | • • • | [a„ : g„] 

The encoding for Class Bindings, [T], is: 

l{Xi : {Bi,C\),--- ,X„ : {B„,C„)}}''=^ Xi = C\Biand ■ ■ ■ X„ : C„B„ 
The encoding [i?] for the Run-Queue is: 



{Bi,Pi),--- ,X„:{B„,P„)}}''=^PiBi\ ••• \P„B„ 



Finally the encoding for a machine state, [T, B, Q, P, RJ = [S'J is: 

IT, B, Q, P, Rj =^ \a\ (def [T] in PB, {Qj, IRJ) 

where {a} = dom{Q). 
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5.3 Properties 



We now prove some interesting properties for the abstract machine. 

Soundness: every state transition in the abstract machine can be viewed as a reduction or congruence 
between their process encodings in TyCO . 

Theorem 1 (Soundness) For S and S' abstract machine states, if S — > S' then [ 5] = [ S"] or 



Proof: enumerate all TyCOAM rules and check the validity of the transitions. 
( ScHED ) we show that: 

IT, B, Q, nil, [B', P) :: i?l = [T, 5', Q, P, R} 

We know that, 

def 



[T,5,0,nil,(5',P)::i?l' 

1 in nil5 I [01 I 

[T, B',Q,P,R} 



|a|(def[Tlinnil5 | [Q] | [i?]) 



since, n\\B = nil and nil \ P = P for any P. 

( Scop ) we show that: 

lT,B,Q,\x\P\ P', Rj = lT,B + {x: a}, Q + {a:»},P\ P' , Rj a fresh 
We know that: 

lT,B,Q,\x\P I 
\a\{denn\n{\x\P\P')B \ {Qj \ [i?]) =„ 
|a|(def [Tlin {\a\P[y,] \ P')B \ {Q} \ {R}) = 
|aa|(def [Tlin {P[y \ P')B \ {Q} \ [i?]) '=5^ 

since \ x\P\Q=\x\(P\Q) ii x ^fn(O). 

I aa I (def [Tlin {P \ P'){B + {x : a]) \ {Q} \ [i?l) = 



since a ^ fn P' 



I aa I (def [Tlin (P \ P')(B + {x : a}) \ nil | {Qj \ lRl)'M 



since nil | P = P, and finally 

lT,B + {x ■.a},Q+{a:»},P \ P' , Rj 



since [a : •I nil. 
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( Def ) we show that: 



IT, B, Q, def D in P\P', Rj ^ {T + T' , B,Q,P\ P' , Rj 
where T' = {X ■.(B,C) \ X = C E D}. We know that: 

[T, 5,0, def Din P\P',R} = 
|a|(def [Tlin (def Din 5 | P')B \ {Qj \ IRJ)":^' 
|a|(def [T] in (def D5 in pB) \ P' B \ [Q] | [i?]) 

Since dom{D) r\fv{Q,R) = 0, when rename the processes obtaining: 

|a|(def [T] in def DB in pB \ P' B \ [Q] | [i?]) = 
|a|(def [T] and DB in pB \ P' B \ [Q] | [i?]) = 
|a|(def [Tl and [T'l in 55 | 5'5 | {Qj \ [51) 
|a|(def [51 and [5'1 in (5 | P')B \ {Qj \ [51)'=^' 
IT + T',B,Q,P I 5', 51 

( RedMsg ) we show that: 

[5,5,0,M</ : [m]|5,51 [5, 5,0 + {a : Ms}, 5, 5 :: (5' + : 5(m)}, 5')1 
where B{u) = a, Q{a) = (B' , M) :: Ms, and M{1) = {x)P'. We know that: 

lT,B,Q,n<l: [^^15,51 
I a I (def [51 in (« < / : [«] | 5)5 | [Ql | [51) 
|a|(def [51 in a< / : [B{u)] \pB \lQ + {a: Ms}} \ aOMB' \ [51) 
|a|(def[5lin55 | IQ + {a : Ms}} \ ((M5')(0)[5(«)] I m) = 
•••I ((x)P')B'[B(u)] I ...'=1' 
•••I ((£)(5'(5-{£})))[5(«)] I ...= 
... I /5'(5_{£})[i?(")/.] I ...4£f 

... \P'(B' + {x:B(u)}) I ---'M 
[5, 5,0 + {a : Ms}, 5, 5 :: (5' + : 5(m)}, 5')1 

( Red Ob J ) we show that: 

[5, B,Q,y> M \ P,R}^ [5, B,Q + {a: ms}, P,R:: {B + {x : B{u)}, 5')1 
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where B{y) = a, Q(a) = [l : [«]):: ms, and M{1) = (x)P' . We know that: 

lT,B,Q,y\>M I 
|a|(def[Tlin {y>M\P)B\ {Q} \ [i?]) 
|a|(def [T] in a 0 MB \ PB \IQ + {a : ms}] \a<\l:[u\ \ {R}) — y 
|a|(def [TlinP5 | {Q + {a : ms]} | M (/)[«] | =' 
••• {{x)P')B[B{u)] \---''^ 

■ ■■ m{p'{B-{x}))m^)] I ••• = 

... I I 

... \P'(B' + {x:B(u)}) I 
[T, B,Q + {a: ms}, P,R:: {B + {x : B{u)}, P')} 

( Red Inst ) we show that: 

IT, B, Q, X[u] \P,R}^ IT, B,Q + {a: ms}, P,R:: {B" + {z : v}, P')} 

where T(X) = (B' , (x)y \> M), B" (y) = a, Q(a) = (I : [v\) :: ms. Mil) = (z)P' and B" = B' + {x : 
B{u)}. We know that: 

lT,B,Q,X[n\ I 
\a\{denn\nX[u\ \ PB \ [Qj \ [i?]) 
|a|(def [TlinX[5(«)] | PB \ {Qj \ [i?]) = 

|a|(def [Tlin [Tl[5(«)] \ ■■■)^:^' 
|a|(def[Tlin {{{x)y t> M)B')[B{u)] \ ■ ■ ■) = 

\a\ (def m in ((y > M){B' - | . . . ) 

|a| (def [Tlin {y > M){B' + {x : B{u)}) \ ■■■)''^ 

...in a\>MB" \PB \ lQ + {a: ms}} \a<\l:[v\ \ {R}) = — y= 

■■■mPB\lQ + {a: ms}} \ {R} \ MB"{l)[v\) = = = 

... I P'{B" + {z:v})''^' 

{T, B,Q + {a: ms}, P,R:: [B" + {z : v}, P')} 

( QueueMsg ) we show that: 

[T, 5, 0, M < / : [v\\P, R} {T, B,Q + {a: ms:: [l : [B{u)])}, P, R} 
where B[u) = a and Q{a) = ms. We know that: 

lT,B,Q,n<l: [iI\\P,R} = 
I a I (def [Tl in (« < / : [«] \ P)B \ {Q} \ [i?]) 

. . .in I a < / : [B(u)] \ PB \ = 

■■■\n PB \lQ}\a<l : [B{u)] \ ■■■ = 
IT, B,Q + {a : ms::{l : [B{u)])}, P, R} 
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( QueueObj ) we show that: 

IT, B,Q,yt>M \P,Rl^ [T, B,Q + {a: Ms:: [B, M)}, P, Rj 
where B{y) = a and Q{a) = Ms. We know that: 

lT,B,Q,yt>M I P,R}^:^' 
|a|(def[Tlin {y>M\P)B\ {Qj \ [i?]) 

• • - in I a 0 MB \ PB \ = 

■■■\n PB \lQj\at>MB \ ■■■ = 
lT,B,Q + {a:Ms::{B,M)},P,R} 

( QueueInst ) we show that: 

lT,B,Q,X[u\ I P,R}^lT,B,Q + {a:Ms::{B",M)},P,R} 
where T{X) = (5', {x)y O M), B" {y) = a, Q{a) = Ms and 5" = B' + {x : B{u)}. We know that: 

lT,B,Q,X[n\ I 

\a\{denn\nX[u\ \ PB \ [Qj \ [i?]) 

|a|(def [TlinX[5(«)] | PB \ {Qj \ [i?]) = 

|a|(def [Tlin [Tl[5(«)] | • • • ) =' 
|a|(def[Tlin {{{x)y t> M)B')[B{u)] \ •••) = 

\a\ (def m in ((y > M){B' - | • • •) = 

|a| (def [Tlin {y > M){B' + {x : B{u)]) \ •••)=' 

•••in a[>MB" \ PB \ [Q] | [i?]) =' 

[T, 5, 0 + {a : Ms:: (5", M)}, T, i?] □ 

Completeness The abstract machine is clearly not complete relative to TyCO . This essentially 
results from two restrictions we imposed on the behavior of processes. The first such restriction is 
easily demonstrated with the following example in TyCO : 

a<\l :[v\ I a 0 {/ : {x)P} | a [> {/ : {x)Q} 

which may reduce as: 

{'h]P \at>{l: {£)Q} or / ,}Q \at>{l: {£)P} 

The corresponding sequence in the abstract machine has the parallel composition operator replaced 
by a concatenation operator (with the same syntax, though). Parallel compositions of atomic 
processes are transformed into strings of processes. The abstract machine goes through these strings 
sequentially, without any kind of re-ordering. Thus the only possible outcome of the above example 
when it is run by the machine is equivalent to the composition: 

{'h]P \at>{l: {£)Q} 

Forcing sequential execution of processes eliminates non-determinism within threads in the abstract 
machine. Also, the use of a run-queue to hold newly generated threads serializes their execution. 
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Non-determinism is lost in a serial implementation of the abstract machine. However in a concurrent 
implementation we could eliminate the ScHED rule and introduce non-determinism in the computation 
due to thread interactions (on shared names). 

The second important restriction is the fact that we close processes for names. This restricts their 
behavior in one fundamental: abstract machine programs are closed entities uncapable to react or 
interface with external object systems. 

At this point it is not clear what the relation is (if any) between the semantics of TyCO and that of 
the abstract machine. 

Communication/Method-closure Queue Invariant: the abstract machine preserves the invari- 
ant that at any time during a computation the queues associated with names have either communi- 
cations or method-closures (or empty). Formally, we have the following lemma: 

Lemma 1 Denote So as the tmtml state of the abstract machine. Then, if So _, _, Q,-, _ then 
VaGdom(Q)'5(a) £ QCoMM orQ{a) e QMeth , 

Proof Outline: Induction on the length of the reduction performed by the abstract machine. 

We start with the initial state of the abstract machine: 

50 = 0,0,0, A* 

where P is the initial thread. There are no queues in this state. The invariant holds trivially. 

Now assume that we are in a generic state: T, B ,Q , P, R for which the invariant holds. We must 
check that after applying any of the reduction rules to such a state the invariant will still holds. 

Rules ScHED and Dee do not affect the queues in Q, so after an application the invariant will still 
hold. Also the ScoP rule creates a new name and an empty queue with it in Q. Since the empty 
queue is both in QComm and QMeth the invariant is preserved. 

The Red and Queue rules affect the queues in a more complex way. We enumerate the possibilities: 

• RedMsg is used whenever the queue being inspected is in QMeth . It removes one of the 
method-closures from the queue. The remainder of the queue (eventually empty) is still in 
QMeth ; 

• Red Ob J (same as above but with the queue in QComm ); 

• Red Inst (same as above but with the queue in QComm ); 

The Red rules preserve the invariant. Similarly, for the Queue rules we have: 

• QueueMsg is used whenever the queue being inspected is in QComm . It adds another 
communication to the end of the queue which obviously remains in QComm ; 

• QueueObj (same as above but with the queue in QMeth ); 

• QueueInst (same as above but with the queue in QMeth ); 

The Queue rules also preserve the invariant. □ 

Absence of Deadlocks: next we prove that the abstract machine does not deadlock for well typed 
programs. 

Definition 1 S is a deadlock state if S ^ _, _, nil, • and S -j^. 
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Definition 1 Let So be the tmtml state of the machine. So deadlocks if So S and S is a deadlock 
state. 

Theorem 1 If P m So = 0, 0, 0, P, • is well-typed then So does not deadlock. 

Proof outline: we know that T, B, Q, P' , R. We analyse the structure of thread P' . 

If it is the empty thread: nil, we have two possibilities: 

• i? = •. In this case we have a state of the form _, _, _, nil, • which by definition is not a deadlock 
state. 

• Rz^ ». In this case we apply the ScHED rule to initiate the execution of a new thread with the 
corresponding bindings. 

Now assume that our thread has the form: P \ P' and show that we may always apply one of the 
reduction rules successfully. We do this by enumeration of the processes in the abstract machine: 

• P =\ X \ P' . Since all bound variables in the initial process are distinct (variable renaming 
assumption) we apply the ScoP rule. 

• P = def D in P. Again, the variable renaming assumption implies that dom(T) fl dom(_D) = 0. 
We apply the Def rule. 

• P = y <ll : [u]. First, y G dom(5) (processes are closed) and a = B{y) G dom((5) (processes are 
closed and well typed). Two situations may now occur: Q{a) G QComm or Q{a) G QMeth . 
This results directly from the queue invariant. If Q{a) G QComm we apply the QueueMsg 
since {«} C dom(5). Otherwise, if Q{a) G QMeth then we have an opportunity to reduce 
and apply the RedMsg rule. This is possible since programs are well typed and hence, the 
method-closure taken from the queue contains a method / : {x)P such that \x\ = \u\. 

• P = y t> M . First, y G dom(5) (processes are closed) and a = B{y) ^ dom((5) (processes 
are closed and well typed). Again the queue invariant ensures that only two situations may 
occur: Q{a) £ QComm or Q{a) £ QMeth . If Q{a) £ QMeth we apply the QueueObj with 
no further checking. If, on the other hand, Q{a) G QComm then we apply the RedObj rule. 
This is possible since programs are well typed and hence, the current object contains a method 
/ : {x)P such that \x\ = \u\. 

• P = X[u]. This is essentially the same as the above, with the additional remark that, since 
programs are closed X G dom(T). 

From the above we conclude that no well typed program deadlocks the abstract machine. □ 



6 Related Work 

Efforts to provide a framework for concurrent object-oriented languages have relied on two fundamen- 
tal approaches: the concept of actors [3, 4] with the associated computational model, and; encodings 
of objects into Milner, Parrow and Walker's 7r-calculus or an equivalent asynchronous formulation 
due to Honda and Tokoro [8]. 

Some actor languages have been implemented with some success such as the ABCL family [26, 25]. 
Moreover, most existing concurrent object-oriented languages incorporate aspects of the actors model 
in their specifications. 
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In recent years researchers have devoted a lot of effort in providing semantics for objects within the 
asynchronous 7r-calculus [8, 24, 16, 12], variations [20, 6] and extensions [7] (for constraint program- 
ming). Although there is extensive theoretical research on the subject, abstract machine specifications 
and implementations of actual models are still scarce [19, 18, 10, 11]. A few programming languages 
based on process calculi have been purposed. Some, such as Pict [19] or Oz [10, 11] have gained some 
prominence. 

The TyCO object calculus on which the abstract machine described in this paper is based is very 
reminescent of Abadi and Cardelli's ^-calculus [1, 2]. Here as in TyCO objects are primitive and 
represented as sums of labelled methods. Labelled method invocation (messages in TyCO ) are also 
present. The calculus has an extra method update operation which is not present in TyCO and is 
fully sequential. TyCO has the same computational power as the asynchronous 7r-calculus [22]. 

Pict is based on an asynchronous form of Milner's 7r-calculus, with the basic abstractions being 
processes and names (channels) . Processes communicate atomically by sending values along shared 
channels. Recursion is modeled by process replication. On the other hand, Oz is based in the 7- 
calculus, where the basic abstractions are: names, variables (logical), procedural abstraction and 
cells. Both calculi are specializations of a more general calculus that is obtained from the polyadic 
TT-calculus by distinguishing between names and variables and making the variables logical. Our 
abstract machine is based on TyCO [20], a form of the asynchonous 7r-calculus where messages 
(labeled output processes with a ml continuation) and objects (non replicated input processes in 
the form of collections of labeled methods) are first class abstractions. Replication of processes is 
modeled through instantiation of recursive classes (objects abstracted on a set of variables) . 

Pict is a pure process-based concurrent programming language. Besides a subset of the basic 
TT-calculus functionality, Pict also defines some higher level abstractions such as templates and 
records (structured values with named fields) and provides a type-inference system. Objects are 
implemented using records. As a result method invocation in such objects is a three-way protocol 
(communication, matching, communication), as opposed to a one-way protocol (communication) in 
our abstract machine. This results from the fact that messages and objects are first-class entities in 
our design. 

Another important property of objects is the fact that method selection is based on labeled transitions. 
Besides a faster invocation protocol this has the added benefit of not producing computational garbage. 
In Pict objects are encoded as records of names. Each method waits on one of these names for 
communication. The creation of an object implies the creation of one new name per method (and 
one for each state variable) and for the method processes to be placed in parallel, thus forcing the 
creation of closures. When a method invocation is received, the body of the method is executed 
with the substitutions performed. This produces a large amount of garbage in the form of unused 
process closures and names, which must be dealt with both in theory and in the context of a real 
implementation. 

Oz combines three major programming paradigms: functional, object-oriented and constraint logic 
programming, in to an high-level programming language. Constraints are built over logical variables 
by first-order logic equations, eventually using a set of predefined predicates. Cells are primitive 
entities that maintain state and provide atomic read-write operations. Procedures have encapsulated 
state so that objects can be defined directly as sets of methods (procedures) acting over their state 
(represented as a set of logical variables). This representation is quite close to objects in our own 
abstract machine if we replace the state held in logical variables with the class formal parameters. 

The Turner Abstract Machine (TAM [19, 18]), which is the basis for the implementation of Pict 
introduced some simplifications into the semantics for the asynchronous TT-calculus to allow for 
an efficient implementation. First, only input processes were allowed to replicate. This is also 
true for our abstract machine since recursion can only occur within objects (instances of classes). 
Furthermore, the form of replicated input processes was changed so that replication occurred only 
after a communication on the channel was received. This property also holds in our abstract machine 
but does not result from any design restriction. An object, instance of some recursive class, can only 
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be replicated when one of its methods is invoked. A recursive call within the body of the method 
may then create a new replica of the object (with possibly distinct argument values). 

Turner realized that 7r-calculus processes were far too pervasive and short lived to allow an efficient 
implementation by mapping them one-to-one with threads. The Pict abstract machine tries to 
maximize the number of processes executed within a thread of control. This is achieved by allowing 
a process to be executed at once instead of making a closure for it and placing it in the run-queue. 
The only exceptions occur when an (replicated) input process closure is taken from one of the queues 
upon reception of a communication. 

On the other hand the Oz abstract machine executes programs (closed for names) made up of threads: 
stacks of expressions. State (in the form of cells) and equations are kept in a blackboard which is 
updated by concurrent threads. New threads are created whenever an expression occurs in the current 
thread that cannot be imediately reduced. The expression is executed in the new thread. Thread 
composition is commutative. 

In our design we introduced a new syntactic category for threads. They are sequences of processes 
linked by the "|" (concatenation) operator. The machine executes threads. All newly created threads 
are placed at the end of the run-queue (in a concurrent implementation they would be run in a 
new thread). Processes within threads are executed without interference from the scheduler, hence 
threads cannot be blocked. Threads are identified with methods from objects. This fact makes for a 
particularly clean model for an object-oriented language where objects are sets of methods atomically 
executed (with some state carried by class parameters) [9]. Moreover, in a concurrent setting, non- 
determinism originates in interactions of threads on shared names. Actually, persistent objects in our 
abstract machine are reminescent of actors [3, 4, 9]. They may initiate communications with other 
objects or even to themselves (by sending messages to self); they may create new objects either by 
prototyping or instantiation and propagate self channels and; they may change behavior after an 
incomming communication. This can be achieved by creating a new object at self with the same 
type (interface) but eventually with distinct method implementations. 

The abstract machine implements the current formulation of TyCO [23] in its full extent. The Pict 
abstract machine, on the other hand, implements the asynchronous 7r-calculus with a few important 
restrictions and semantic nuances. First, the choice (summation) construct is not supported directly 
in the abstract machine. Rather it is provided by the implementation as an extra library module. This 
is both to allow an efficient run-time representation of names and avoid the costly garbage collection 
of unused names in choice patterns [17]. Also, the semantics for replication was restricted in such a 
way that (replication) can only occur in input processes after a communication is received. This is 
to allow the abstract machine to efficiently identify the places where process replication occurs [19]. 

An implementation of the abstract machine is underway with both the compiler and run-time 
system nearly completed. Future work will focus on performance evaluation and optimizing the 
system. Latter we will introduce higher level constructs into the abstract syntax, such as expressions 
(functional, pattern matching, algebraic types) and inheritance. 
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